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Within a component-based approach allowing dynamic reconhgurations, sequences of successive 
reconhguration operations are expressed by means of reconfiguration paths, possibly inhnite. We 
show that a subclass of such paths can be modelled by hnite state automata. This feature allows us to 
use techniques related to model-checking to prove some architectural, event, and temporal properties 
related to dynamic reconhguration. Our method is proved correct w.r.t. these properties’ dehnition. 
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1 Introduction 

This article aims to show that some properties related to component-based software with reconfigura¬ 
tions can be proved by implementations based on model-checking techniques. Let us recall that most 
of component-based systems aim to run for a large period of time, so some components may fail or 
need to be improved or replaced. That is why dynamic reconfigurations increase the availability and 
reliability of such systems by allowing their architecture to evolve at runtime. Dynamic reconfigurations 
of software architectures is an active research topic |[Tl|3l|T8l[T3|20l, motivated by practical distributed 
applications. Such applications are put into action by means of toolboxes such as Fractal |4]. In addi¬ 
tion, if we consider systems with high-safety requirements, the verification of architectural, event and 
temporal properties may be crucial. Some proposals exist, e.g., ifT^ . which focus on the verification of 
properties related to the behaviour of component-based systems. Within this framework, Q proposes 
FTPlj^ a temporal logic for dynamic reconfigurations, including such properties. These properties apply 
to successive configurations —or component models —, chaining reconfigurations being modelled by re¬ 
configuration paths. Since FTPL is based on first-order predicate logic, such properties are undecidable 
in general, there only exist partial solutions for proving them. 

Within this framework, ifT^ IT7]| developed methods that work whilst software is running and may be 
reconfigured. Therefore we know if a property holds step by step, until the current runtime state. Our 
method proceeds from a different point of view; our modus operandi is more related to the approach of a 
procedure’s developer when such a developer aims to prove its procedure before deploying it and putting 
it into action. More precisely, we propose a method for verifying such properties, not at runtime, but on 
a static abstraction of the reconfiguration model, so we aim to ensure that such a property holds before 
the software is deployed and working, that is, at design-time. In other words, given a reconfiguration 
path that may be applied when the software is running, we aim to ensure that a property holds if this path 
is actually applied when the software works. Our method is suitable for finite reconfiguration paths, but 
also for infinite ones, provided that they can be modelled by finite expressions, that is, by using the ‘+’ 
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operator of regular expressions at a final position. In other words, our method applies to finite reconfig¬ 
uration paths, and also to cycles without continuation. This last condition may appear as restrictive, but 
in practice, the same sequences are often repeated: a component may be stopped in some circumstances, 
restarted in other circumstances, and so on. So the repetition of identical reconfiguration sequences 
seems to us to be interesting in practice, even if they are only a subset of infinite reconfiguration paths. 
Besides, our implementation is operational, fits the notion of reconfiguration path and opens promising 
ways about properties related to reconfigurations. In addition, we can prove that this implementation is 
correct w.r.t. the definitions given in I®. Sectionj^gives some recalls about the component model we use, 
our operations of reconfiguration, and the temporal logic for dynamic reconfigurations. Of course, most 
definitions presented in this section come from |I2[T0l|TTl|T6l. Section is devoted to the main outlines 
of our framework. Then we give some examples of our programs in Sectionand study the correctness 
of these implementations w.r.t. the operators defined in Section In this article, we do not examine 
the implementation of all the operators—given in lfT4l — but our examples are representative. Section 
discusses some advantages and drawbacks of our method, in comparison with other approaches. It also 
introduces future work. 

2 Architectural Reconfiguration Model 

First we recall how our component model is organised. Then we sum up the operations used for re¬ 
configuring an architecture. Last, we make precise operators used in FTPL, the temporal logic used in 
ini [TOl nil [161 for dynamic reconfigurations. 

2.1 Component Model 

Roughly speaking, a component model describes an architecture of components. Some simpler compo¬ 
nents may be subcomponents of a composite one, and components may be linked. Let be a set of 
class names —in the sense used in object-oriented programming—a component is defined by: 

• three pairwise-disjoint sets of parameter^P^ , input port names and output port names 

• the class % encompassing the services implemented by the component; 

• additional functions to get access to the class of a parameter or port (Tc : /V U 5^), or 

to a parameter’s value (y^ : ^ U=^); 

• the set sub-C‘^ of its subcomponents if the ^ component is composite. Of course, the binary 
relation ‘is a subcomponent of’ must be a direct acyclic graph. 

A composite component cannot have parameters. The bindings of ports form a set B of couples of output 
and input port names, being the same type. Delegation links, between composite component ports and 
ports of contained components form a set D of couples, too. As an example of a component-based 
architecture, possible components of an HTTP server are given in Fig.[T] 

2.2 Configuration Properties 

Example 1 Looking at Fig. [^’5 architecture, we can notice that the CacheHandler component is con¬ 
nected to the RequestHandler component through their respective ports cache and getCache. Vfe can 

^Some authors use the term ‘attributes’ instead. A parameter is related to an internal feature, e.g., the maximum number of 
messages a component can process. 
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Figure 1: Architecture of an HTTP server ifTTIl . 


express this configuration property— so-called CacheConnected— as follows: 

B 3 (cachecacheHandlerjgS'tCachej^gq^gg^jj^jjQ^gj.) 

In fact, such properties—that may be viewed as constraints —are specified using first-order logic 
formulas over constants (‘true’, ‘false’), variables, sets and functions defined in § |2.1[ predicates 
(=, G,. • .)> connectors (A, V,...) and quantifiers (V, 3). These configuration properties form a set denoted 
by CP. 

2.3 Reconfiguration Operations 

Primitive reconfiguration operations have been defined, they applied to a component architecture, and 
the output is a component architecture, toc|^ They are the addition or removal of a component, the 
addition or removal of a binding, the update of a parameter’s value. Let us notice that the result of 
such an operation is consistent from a point of view related to software architecture: for example, a 
component is stopped before it is removed, and removing it causes all of its bindings to be removed, too. 
Another point is that these operations are robust in the sense that they behave like the identity function 
if the corresponding operation cannot be performed. For example, if you try to remove a component 
not included in an architecture, the original architecture will be returned. The same if you try to add 
a component already included in the architecture|^ As a consequence, these topological operations— 
addition or removal of a component or a binding—are idempotent: applying such an operation twice 
results in the same effect than applying it once. General reconfiguration operations on an architecture 
are combinations of primitive ones, and form a set denoted by The set of evolution operations is 
^run = {run} where run is an action modelling that all the stopped components are restarted and 
the software is running. 

Definition 2 (lUOlflgP The operational semantics of component systems with reconfigurations is de¬ 
fined by the labelled transition system .5C = {C,C^where C = {c,ci,C 2 ,...} is a set of 
configurations, C® C C is a set of initial configurations, ffrun A a finite set of evolution operations, 
—)■ C C X l^run X C is the reconfiguration relation, and I: C ^ CP is a total function to label each c G C 
with the largest conjunction of cp G CP evaluated to ‘true’ over Mmn- 


^They may be viewed as graph transformations applied to component models if we consider such models as graphs. 
‘^The reason: the name of a component—part of its definition—can only identify one component. 
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Figure 2: Part of an evolution path of Fig.[TJs HTTP server architecture ifTll . 


Let us note c ^ c' when a target configuration c' is reached from a configuration c by an evolution 
op G i%run- Given the model S = {C,C ^an evolution path a of 5 is a (possibly infinite) 
sequence of component models co,ci,C 2 ,... such that V/ G N,3op G f%run,Ci ^ c,+i G —)•. We write 
‘a[/]’ to denote the /th element of a path a. The notation ‘a- ’ denotes the suffix pafh a[/], a'[/ + 1],... 
and ‘ a/ ’ {j G N) denofes fhe segmenf pafh a [/], a [/ +1 ],..., a [y — 1 ], a [y]. An example of reconfiguration 
pafh allowing Fig. [T]lo be reached from a simpler archifecfure is given in Fig. |^(Fig. [TJs archifecfure is 
labelled by fhe C 4 configuration). 

2.4 Temporal Logic 

FTPL contains events from reconfiguration operations, trace properties, and temporal properties, respec¬ 
tively denoted by ‘evenf, ‘trace’, and ‘temp’ in the following. Hereafter we only give some operators of 
FTPL, in particular those used in the implementations we describe. For more details about this temporal 
logic, see ifTOlfTfil . FTPL’s syntax is defined by: 

{temp) ::= after {event) {temp) \ before {event) {trace) | ... 

{trace) ::= always cp \ eventually cp\ ... 

{event) ::= op normal | op exceptional | op terminates 

where ‘cp’ is a configuration property and ‘op’ a reconfiguration operation. Let cp in CP be a configura¬ 
tion property and c a configuration, c satisfies cp, written ‘c |= cp’ when l{c) =► cp. Otherwise, we write 
‘c ^ cp’ when c does not satisfy cp. 

Definition 3 ( IlIOll ) Let o be an evolution path, the FTPL semantics is defined by induction on the form 
of the formulas as follow ^^^in the following, i G N—.' 

• for the events: 

a [/] 1= op normal 
a [/] 1= op exceptional 
a [/] 1= op terminates 

• for the trace properties: 

a 1= always cp if V/: / > 0 (7[/] ^ cp 

a 1= eventually cp if 3/: / > 0 (7[/] ^ cp 


if i>0A a[i - 1] / o[i] A a[/ - 1] a[/] G — )■ 
if / > 0 A a[i - 1] = a[/] A a[/ -1] a[/] G — > 
if a [/] 1= op normal V a [/] |= op exceptional 


^For a complete definition including all the operators, see cni. 
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Figure 3: Reconfiguration path viewed as a finite state automaton. 


• for the temporal properties: 


a \= after event temp if V/: / > 0 A a[/] |= event |= temp 
o ^ before event trace if V/: / > 0 A a[/] |= event |= trace 


Example A If we consider the evolution path of Fig. ^again, we can now express that after calling the 
AddCacheHandler reconfiguration operation, the CacheHandler component is always connected to the 
RequestHandler component —CacheConnected is the configuration property defined in Example^I^: 

after AddCacheHandler normal always CacheConnected 


3 Our Method’s Main Outlines 

3.1 Basic Idea 

Our basic idea is that a finite reconfiguration path may be viewed as a particular case of a finite state 
automaton, more precisely, a kind of Biichi automaton. This property still holds if an infinite reconfig¬ 
uration path may be expressed using the ‘-I-’ operator of regular expressions at a final position. As an 
example, let us consider the following reconfiguration path, related to Fig.[^ 

run RemoveCacheHandler AddCacheHandler 

(MemorySizeUp run AddFileServer DurationValidityUp DeleteFileServer) + 

it can be modelled by the automaton pictured in Fig. (before cycling, the states qQ,q\,q\,... have 
been respectively named in connection to the successive component models co,ci,Cj,... , 05 . Let us 
recall that a finite state automaton .s^ is defined by a set Q of states, a set L of transition labels, and a 
set r C g X L X 2 of transitions. Like in Definition for systems with reconfigurations, there exists a 
function I'. CP, which labels each q state with the largest conjunction of cp G CP evaluated to ‘true’ 
for the q state. 

Within this framework, a state of such an automaton modelling a reconfiguration path is a component 
model, initial or got by means of successive reconfiguration operations—^primitive or built by chaining 
primitive operations—or "run" operations. A transition consists of applying such an evolution operation. 
Of course, such automata are particular cases: there is only one initial state, and only one transition can 
be applied from a state. More formally, the T set of such an automaton satisfies: 

^q,qQ,q\ G Q^hM GL, (^,/o,^o) £ T F{q,li,qi) £T ^lo = hAqo = q\ 
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Figure 4: Our organisation. 


In the following, we use the notations ‘succj^{q) = qo’ or ‘q q^ for the qo state reached from the q 
state by a unique transition: succj^{q) =qo £ L, {q,lo,qo) G T. If a reconfiguration path is finite, 

the corresponding automaton has a final sfafe. Ofherwise (like in fhe example above), fhere is no final 
sfafe in fhe sense fhaf no fransifion can be performed. If a sfafe of such an aufomafon is reached several 
limes—e.g., fhe q 2 sfafe in Fig.|^ reached after q[ and q^ —considering fhaf fhe whole system is back lo 
a previous sfafe is nof exacl, because some parameters can have been updated: Ibis is fhe case in Fig.j^s 
example, aboul fhe memory’s size and durafion validily. As a consequence, some properties related lo 


componenls’ parameters may nof hold. We will go back on Ihis poinl al fhe end of § 4.2 


3.2 Modus Operandi 


We use several programming languages wifhin our framework. Al firsl glance, fhis choice infroduces 
some complexify, bul in realily, each language is used suilably. Fig. shows how lasks are organised 
wifhin our archileclure—being successive componenl models. In our implemenlalion, fhe ADlj^ 
we use for our componenl models is TACOS+/XML lfT3l . This language using XMLQlike synlax is com¬ 
parable wifh ofher ADLs, so from a Iheorelical poinf of view, we could use any ADL, anofher example 
being Fractal/ADL 0, bul we mention fhaf fhe organisation of TACOS-t/XML lexis make very easy fhe 


programming of primifive reconfiguralion operations menlioned in § 2.3 fhaf is why we chose fhis ADL. 
Reconfigurations operafions are implemented using XSLlj^ fhe inpul and oufpuf are TACOS-t/XML files. 
When fhe soflware is running, only one componenl model is in use, so fhaf may be viewed as fhe identify 
funclion applied lo a componenl model. 

A shorl example of such a TACOS-t/XML file is given in Fig. In our implemenlalion, configura¬ 
tion properlies are expressed using XQuery programs 12^ . reluming True’ or ‘fake’ll as exemplified 
in Fig. aboul fhe CacheConnected properly. If is well-known fhaf XML dialecfs are very suilable for 
specifying archifeclures—mosl of ADLs use fhis synlax—and XSLT/XQuery are very appropriate for op¬ 
erafions modelling reconfigurafions and properly checks. Chaining reconfigurafions and properly checks 
is expressed by an implemenlalion of aulomala. There is no difficully aboul Ihe implemenlalion of recon- 


^Architecture Definition Language. 

^extensible Markup Language. 

^extensible Stylesheet Language Transformations, the language of transformations used for XML documents na. Let us 
note that if another ADL is used within a project, there exist XSLT programs giving equivalent descriptions in TACOS/XML Ga¬ 
in particular, that is the case for Fractal/ADL. 

®Of course, other choices are possible, in particular XSLT stylesheets. Our point of view: XQuery programs are more 
concise, what seems to us to be interesting for verifying architectural properties. Besides, our XQuery programs return ‘true’ 
or ‘false’, but we could easily modify them in order to output a counter-example if a property does not hold. 
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<tacos:components ...> ... 

<tacos:component - specifications> 

<tacos:composite - component id="HttpServer" path = "HttpServer"> 

<tacos:port ref="Trequest" role="server" name="httpRequest"/> ... 
<tacos:refers-to ref="RequestReceiver"/> 

<tacos:refers-to ref="RequestHandler"/> ... 

</tacos:composite - component > 

<tacos:component id="RequestReceiver" path="HttpServer/RequestReceiver"> 
<tacos:port ref="Trequest" role="server" name="request"/> ... 

</tacos:component> 

<tacos:component id="RequestHandler" path="HttpServer/RequestHandler"> 
<tacos:port ref="Thandler" role="server" name="handler"/> ... 

<taco s:attributes signature = "RequestHandlerAttributes"> 

<tacos:attribute name="deviation" value="50"/> ... 

</tacos:attributes> ... 

</tacos:component> ... 

</tacos:component-specifications> ... 

<tacos:binding-specifications> 

<tacos:binding from="request" to="httpRequest" server="RequestReceiver" 
client="HttpServer"/> 

<tacos:binding from="handler" to="getHandler" server="RequestHandler" 
cllent="RequestReceiver"/> ... 
</tacos:binding-specifications> 

</tacos:components > 


Figure 5: Example of a component architecture described by means of TACOS+/XML. 


figuration operations and property checks, so the descriptions put hereafter concern the part implemented 
by means of automata. 

3.3 Types Used 

In this paper, we describe our checking functions at a high level. Hereafter we make precise the types 
used, in order to ease the reading of our functions. The formalism we used is close to type definitions in 
strong typed functional programming languages like Standard ML Il22]l or Haskell llHl . Of course, we 
assume that some types used hereafter—e.g., ‘bool’, ‘int’—are predefined. 

As abovementioned, an evolution operation is either the identity function, which expresses that the 
software is running, or a reconfiguration operation, which is implemented by applying an XSLT stylesheet 
to an XML document and getting the result as another XML document. At a higher-level, such an evolution 
operation may be viewed as a function which applies to a component model and returns a component 
model. Likewise, checking a property may be viewed as a function which applies to a component model 
and returns a boolean value. Assuming that the component-model type has already been defined, we 
introduce these two function types as: 

type evolution-operation = component-model —component-model 
type check-property = component-model —bool 

Let state be the type used for a state of our automata, starting from such a state and a configuration— 
component model—is expressed by the following type: 

type path-check = state x component-model —)■ bool 
This path-check type is used within: 

function check-after : evolution-operation x path-check —path-check 
function check-always : check-property —)> path-check 
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(: Some declarations omitted. ‘$iilename’ is the XML file analysed. :) 

some Sbinding as element(tacos:binding) in 

doc($filename)/tacos:components/tacos:binding-specifications/tacos:binding 
satisfies 

data($binding/(§from) eq "cache" and data($binding/(§to) eq "getCache" and 
data($binding/(§server) eq "cacheHandler" and data($binding/@client) eq "requestHandler" 


Figure 6: The CacheConnected property expressed using XQuery. 


In other words, check-always (check-p) (q,c) applies the check-p function along the q state, its succes¬ 
sor, and so on, starting from the c component model. The result of this expression is a boolean value. As 
soon as applying the check-p function yields ‘false’, the process stops and the result is ‘false’. Likewise, 
check-after(e,c/ieck-/) iq,c) also starts from the q state and the c component model; it applies the 
check-f function as soon as the e event is detected as a transition of the automata. The property related 
to the check-f function is to be checked for all the component models resulting from the application of 
the successive transitions. As a more complete example, the translation of the formula ‘after e always 
cp’—where e is an event and cp a configuration property—is check-after(r, check-always (cp)), 
which is a function that applies on a path, starting from a state and component model. The process 
starts from the initial state of the automaton. Of course, there are similar declarations for the functions 
check-before and check-eventually (cf. § 2.41. 


3.4 Ordering States of Automata 

In this section, we introduce some notions related to our automata—they do not hold about general 
automata—and used in the following. The states of our automata modelling reconfiguration paths can be 
ordered with respect to the transitions performed before cycling. Let be such an automaton, if q and 
q' are two states of : 

q<q d(^i,... ^ q\ ^ ^ qn ^ ^ and ^,^ 1 ,... are pairwise-dinerent. 

The notation ‘q <q'" stands for ‘q < q' Vq = q'\ The only transition which does not satisfy this property 
is the transition going back to a state already explored, it starts from the state denoted by q-max^. If we 
consider the s/q automaton pictured at Fig.j^ qo < qi < q\ < q 2 < q 3 < q^ < q 4 < qs = q-max^. 

4 Our Method 

4.1 Functions 

Our main idea is quite comparable to the modus operandi of a model-checker when it checks the suc¬ 
cessive states of an automaton in the sense that we mark all the successive functions of a reconfiguration 
path. The possible values of such a mark are: 

unchecked the initial mark for the steps not yet explored within a reconfiguration path; 

again if a universal property (for all the members of a suffix pafh) is being checked, if musf be checked 
again af fhis sfep if if is explored again; 
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check-atter(.e,check-f)(.q,c) —!• 
if mark(^) == again then true 
else // mark(^) == unchecked 

mark(^) ■<— again ; cq ■<— t{q)[c) ; 

if t(^) == e then check-f isucCj^ iq) ,0^) else check-after(e,c/jecfc-/) (succ^ (g) ,Co) 
end if 
end if 
end 


check-always(c/iecfc-p) (ij’.c) — 

check-p{c) A if mark((^) == checked then true 

else // mark(g) == unchecked V mark(17) == again 

mark(g) <— checked ; check-always (c/jecfe-p) (succ^ (<7) , t (^) (c) ) 
end if ; 


end 


Figure 7: Checking properties: two implementations. 


checked the property has already been checked, and no additional check is needed if this step is explored 
again. 

So, such an automaton modelling a reconfiguration path is pre-processed and its states are marked as 
unchecked. The mark of a <7 state is denoted by mark(^). The transition label starting from such a state 
is denoted by t iq), let us recall that such a transition is the evolution-operation type, so it can be 
applied to a component model c to get the next component model t (^) (c). 

We give two implementations of checking properties in Fig. the functions check-after and 
check-always. We use a high-level functional pseudo-language, except for updating marks, which is 
done by means of side effects. A complete implementation is available at |[T4l . including other features 
of FTPL, with similar programming techniques and similar methods for proving the termination of our 
functions and the correctness w.r.t. the definitions given in ij^lTOll. 

4.2 Implementations’ Correctness 

4.2.1 Termination 

Proposition 5 The function check-after terminates. 

Let qo be the initial state of our automaton, a principal call of the check-after function is: 

check-a.fter{e,check-f){qo,c) 

where e is an event, check-f a check function being path-check type, c a component model. Recursive 
calls of this function satisfy the invariant: 


V <?7 : qo < qj < qi,ma.Tk{qj) = again 


when it is applied to the qi state. Let q^ = succ^{qi). If qi < q^, the invariant holds. If qi = q-max^, 
then 'iqj : qo < qj < q-max^,mark(^ 7 ) = again, that is, the next recursive call applies to a state whose 
mark is again. Such a call terminates. 

Proposition 6 The function check-always terminates. 
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This termination proof is similar: a pass is performed by the check-always function, but this pass 
may start after the beginning of a cycle, and the cycle may have to be entered a second time. Globally, 
two passes may be needed for an expression such that check-after(e,check-always(cp)). Before 
reaching the end of a cycle, the invariant is: 

\/qj : qo < qj < ^,-,mark(( 7 y) = checked Vniark(( 7 y) = again 

when the check-always function is applied to the qt state. Roughly speaking, when a cycle is performed, 
the mark has been set either to again, in which case the property has to be checked again, or to checked, 
in which case our function concludes that the temporal property is true. If the mark has been set to again, 
it means that the checking of the temporal property ‘always cp’ had not begun yet; for example, if we 
were processing the ‘after’ part of ‘after e always cp’. If re-entering a cycle is needed, the invariant is: 

: succ^(q-max^) < qj < ^,-,mark(^y) = checked 

qi being the current state. Let us recall that succ^(q-max^) is the first state of the cycle of the au¬ 
tomaton. If the current state reaches the greatest state w.r.t. the ’<’ relation among states, the following 
recursive call of check-always is performed with the situation: 

\/qj : succ^(q-max^) < qj < q-max^,mark(^y) = checked 

that is, the check-always function terminates at this next call. 

4.2.2 Correctness 

Concerning the check-after function, let us examine the definition of the after temporal property: 
a 1= after e temp if V/ : (/ > 0 A a[/] \= e gJ |= temp) — where a is a reconfiguration path, e an 
event, temp a temporal property. It is sufficient to check this property on the first occurrence of the 
e event in the transitions handled by our check-after function. The set I of the i integers such that 
/ > 0 A a[/] ^ r is a subset of N. Since / is a subset of a well-ordered set, it has a smallest element iq. So 
we have |= temp and V/ G I, /q < i- As a consequence, |= temp aj |= temp for each element 
i of I. Let us consider a call check-af ter(r,c/zrck-/)(( 7 ;,c,), where c,- is the component model we got in 
the qi state, and the following invariant—let us recall that is the initial state—: 

v<yy. <^o — qj ^ qii^j ^ ^ 

holds. If t(/) = e, we check the property implemented by check-f from the qi state of the automaton, cor¬ 
responding to the suffix of the reconfiguration path starting at the qi state—that is, aj if states are indexed 
by natural numbers—which is correct w.r.t. the specification. If t(/) ^ e, the check-after function is 
recursively called and the invariant holds. By Proposition!^ if such a call of the check-after function 
terminates with mark(< 7 ,) = again, that means that all the automaton’s states have been marked again. 
Such a mark is put whenever the e event is not found. Consequently, this event does not appear and the 
result is the ‘true’ value. 

The case of the check- always function is more subtle. Let us recall that after performing a cycle, the 
mark is set either to again, in which case the property has to be checked again, or to checked, in which 
case our function concludes that the temporal property is true. This is not true for any reconfiguration 
operation, but holds for a large subset. Let us assume that we have processed a reconfiguration operation 
op on a c configuration. If we process op again after cycling throughout our reconfiguration operations. 
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the current component model may be different from c. In other words, the system is not necessarily 
in the same state. A simple counter-example: let us consider Fig. and a reconfiguration operation 
'5Fdeviation++ which increments the deviation attribute of the RequestHandler component. If this op¬ 
eration is repeated and the property to be checked is ‘always deviation < 100’, this property will be 
true at the first pass but will fail after some iterations. Now let us consider the reconfiguration operation 

deviation ^ 99 which scts this deviation attribute to a new value, less than 100. If this reconfigu¬ 
ration operation is repeated, the property ‘deviation < 100’ will always hold. For our purpose, the 
difference between the two operators oPdeviation++ deviation ^ 99 that the latter is idempotent, 

not the former. So using a cycle whose global composition of all the reconfiguration operations is idem- 
potent is sufficient in order for our check-always function to behave correctly w.r.t. the specification of 
the ‘always’ operator. It is necessary for checking any property without further hypotheses. But—as an 
example—another approach is accurate if properties to be checked do not deal with parameters’ values. 
The condition of correctness is the same: the global configuration of all the reconfiguration operations 
of the cycle must be idempotent, but reconfiguration operations dealing with parameters can be ignored. 
Let us recall that most reconfiguration operations introduced in § |2.3| are idempotent. For example, let us 
recall that if we try to remove a component not included in a configuration or add a component already 
included, this configuration is unchanged. Consequently, applying this operation once or more causes the 
same effect. Similar remarks can be done for the addition of a component, the addition or removal of a 
binding. In general, the composition of idempotent operations is not necessarily an idempotent function. 
In our case, we can show the composition of topological operations is idempotent. To give a sketch of 
the proof, let us mention that for two idempotent functions f,g:X^X{X being a set), if go f = f o g, 
then go / is idempotent, too. In fact: 

{g°f)°{g°f) = g°{f°g)°f 

= gogofof 

= g°f 

The complete proof is tedious, because many combinations are to be examined. Some pairs of topo¬ 
logical operations yield the identity functions when composed, other pairs are commutative w.r.t. the 
‘o’ composition operation. Examples coming from Fig. are the transitions labelled by the events 
AddFileServer and DeleteFileServer, which yield the identity function, whereas the transitions labelled 
by AddFileServer and DurationValidityUp are commutative. 

5 Discussion and Future Work 

Within the framework sketched at § |3.2[ our automata have been implemented using the Scheme pro¬ 
gramming language ll24]l . The complete implementation can be found in ifTdl . and ifTSl describes our 
functions in a way closer to this implementation, giving more details about the Scheme structures we 
used. The descriptions of this paper allow us to be more related to a theoretical model, and to emphasise 
that our method is close to algorithms based on marks and used in model-checking, e.g., |l6l|7ll23l. Our 
implementation uses Scheme stream^^fox reconfiguration paths and includes the fact that a reconfig¬ 
uration path may be infinite, but only cycles without continuation are processed as shown in § [^ In 
practice, our functions are called with an additional argument for the maximum number of iterations 
along a reconfiguration path. If this number is reached, our functions return the part of the path which 

*®That is, potentially infinite lists, as implemented within lazy functional programming languages. 
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is not explored yet and the component model reached, so end-users can launch the process again if they 
wish. In this case, we do not perform complete checking, but only bounded checking. With our im¬ 
plementation, we experienced the property given at Example and the reconfiguration path pictured at 
Fig.[^ the result is ‘true’, as expected. We also experienced some variants: for example, if cycling is per¬ 
formed from the state to the q\ state (cf. Fig.[^, the result is ’true’, too, and only the first occurrence 
of the AddCacheHandler event is different from the identity function. As a second variant, if cycling 
is done from the q^ state to the q\ state, the result is ‘false’: when the states q\ and q\ are explored by 
the check-always function, the property CacheConnected must be checked and it fails about the q\ 
state; however, let us notice that such check after the <72 state are not performed if this state is reached 
after cycling from the q^ state. Practically we have been able to carry out all the examples of ifTOll ; these 
tests confirmed results expressed theoretically in that article. Other tests based on reconfigurations of 
a location componenj^ are successful. From a theoretical point of view, we explore as few states as 
possible. In practice, our programs’ efficiency is good, in despite of the communications among several 
programming languages. In addition, we plan to study implementation techniques in order to improve 
efficiency. We also plan to apply our technique to large-sized case studies. 

The idea of modelling reconfiguration paths by means of automata seems to us to be very promis¬ 
ing, and we plan to go thoroughly into more expressive cases. In this paper, we are not interested in 
the reasons of reconfigurations: most often they are implemented by means of policies in systems like 
Fractal, some examples can be found in [!8i|. Reconfiguration operations may be viewed as operations 
solving unexpected situations, but most of these situations are planned by policies and can be simulated. 
We plan to enlarge our language of reconfiguration paths, in order to encompass policies. Fikewise, we 
plan to be able to express reconfiguration alternatives. In other words, we plan to build more ambitious 
automata from more expressive reconfiguration paths, provided that we can check interesting properties. 
This should lead us to propose new algorithms, but also to a new version of the temporal operators given 
in § 2.4 The operators given in ifTOlfT^ refer to a linear-time logic, whereas reconfiguration alternatives 
should be based on branching-time logic. Explaining this difference is easy: ifTOl |T6l observe a pro¬ 
cess in progress, at runtime, whereas reconfiguration alternative are possible futures we explore before 
the software is deployed and put into action. Another idea could be to move the Model Driven Engi¬ 
neering technical space [2, who would provide more expressive power about model transformations. 
Other approaches are closer to a semantic level: for example, lITSl models reconfiguration operations 
by means of graph rewriting and uses formal verification techniques along graphs to check properties 
related to reconfigurations. A comparable approach is followed in ifTTl . As another example, Q defines 
a calculus allowing policies. Our approach concerns a more syntacfic level because our reconfiguration 
operations apply to component models, and result in other component models. Fikewise, we assume that 
the properties we check can be verified syntacfically on component models: that is the case, at least for 
topological properties. Our approach does not cover all cases of reconfiguration paths, but in practice, 
the same sequences are often repeated, as mentioned in the introduction. 


6 Conclusion 

As mentioned above, the starting notions, recalled in §[^ come from |l9l|T0l[IIl[T6l. Our contribution is 
our checking method explained in § |^ Practically, it has been actually implemented. Theoretically, we 
have shown that our modus operandi is correct w.r.t. the definitions. Our contribution also includes the 
relationship between properties related to reconfiguration operations and techniques used within model- 


**This example is also used in I13II17I . 
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checking. We think that using such model-checking techniques for properties related to component- 
based software with possible reconfigurations is an open way to interesting experiments, theoretically 
as well as practically. Our bridge between reconfiguration operations and model-checking techniques 
shows that tools developed for the analysis of systems can be reused for the analysis of reconfiguration 
by simulation of reconfiguration paths. It is well-known that model-checking techniques can validate 
a model of a system, not the system itself. So does our method: as mentioned in the introduction, we 
do not run components: we only perform a static analysis at design-time. Our approach cannot replace 
methods applied at runtime ifTTlfT^ . when the software has already been deployed and is working, but 
we think that our method can provide some help at design-time. 
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